Frans Pop reported recently that the initramfs did not fit in the flash of the QNAP TS-109 when you used LVM. We had problems with initramfs images that were too large before (on the NSLU2). By default, initramfs-tools uses the MODULES=most setting which puts all modules that might be of interest to booting a machine in the initramfs. This is a good idea on a PC where the hardware can change a lot, but it makes less sense on most NAS devices. Frans has now changed debian-installer so the MODULES policy can be chosen during the installation. His change allowed architecture specific defaults, so I've changed ARM to use MODULES=dep. debian-installer will now create the file /etc/initramfs-tools/conf.d/driver-policy with a MODULES setting that will override that from /etc/initramfs-tools/initramfs.conf. On QNAP devices, I intend to only support MODULES=dep installations, so please change your configuration if you've installed Debian already. On the NSLU2, MODULES=most will of course continue to be supported.

Another point release for Etch has been done; now it's the time for the CD team to roll out new images after the next mirror pulse. The official announcements (prepared by Alexander Reichle-Schmehl, thanks!) will follow shortly afterwards. FTP master of the day was Joerg Jaspert, who did his first point release since Woody, as he told us on IRC. We appreciate your work and you spending your time that shortly before going to Argentina. This point release includes the etchnhalf update introducing a new kernel image (based on 2.6.24) and some driver updates. Additionally the infamous openssl hole will be fixed for good, even for new installs. Again I want to present you a list of people who contributed to this release. It cannot be complete as I got the information out of the Changed-by fields of the uploads.

• akira yamada
• Alexander Sack
• Alexander Schmehl
• A Mennucc1
• Andrea De Iacovo
• Andres Salomon
• Aurelien Jarno
• Charles Plessy
• Christian Perrier
• Christian Welzel
• Colin Watson
• dann frazier (indefatigable kernel worker, most sourceful uploads)
• Darren Salt
• Devin Carraway (3rd place of sourceful uploads, due to security work)
• Emmanuel Lacour
• Eric Dorland
• Fabio Tranchitella
• Faidon Liambotis
• Fathi Boudra
• Florian Weimer
• Francesco Paolo Lovergine
• Francois Marier
• Frank Lichtenheld
• Frans Pop (thanks for your d-i work!)
• Frederic Peters
• Gregory Colpart
• Holger Levsen
• Jan Wagner
• Jay Berkenbilt
• J r my Bobbio
• Joey Hess
• Joey Schulze
• Josselin Mouette
• Julien Cristau
• Kai Hendry
• Kurt Roeckx
• LaMont Jones
• Laszlo Boszormenyi
• Martin Pitt
• maximilian attems
• Michael Biebl
• Michael Koch
• Mike Hommey
• Moritz Muehlenhoff
• Noah Meyerhans
• Ola Lundqvist
• Otavio Salvador
• Patrick Matth i
• Petter Reinholdtsen
• Philipp Kern
• Pierre Habouzit
• Raphael Hertzog
• Rene Engelhard
• Robert Millan
• Roberto Lumbreras
• Roland Mas
• Romain Beauxis
• Russ Allbery
• Sean Finney
• Stefan Fritsch
• Steffen Joeris
• Stephen Gran
• Steve Kemp
• Sune Vuorela
• Thijs Kinkhorst (2nd place of sourceful uploads, due to security work)
• Thomas Viehmann
• Toni Mueller
• Tzafrir Cohen

From the Release Team we had dann frazier (who drove the important kernel part of etchnhalf), Luk Claes, Neil McGovern, Andreas Barth, Martin Zobel-Helas and me working on it. ;-)

Last news I gave for D-I and related stuff l10n completion was on June 15th. We're now one month later, so let's see what happened since then. D-I "level 1" (ie the core D-I) had several templates changes which bringed the translation ratio from 100% to 99% and below several times, for all languages. Several teams have still been able to cope with that. Other levels had no changes and I therefore spent some time nagging them to complete the missing bits here and there. The current status is:

• Level 1 (core D-I): 20 complete languages (be cs de eu fi fr gl gu ja ko nl pt pt_BR ro ru sk sv th tr vi) just like we had on June 15th
• Level 1 + Level 2 (packages with strings used in default installs): 20 complete languages as well (the same ones of course). Big improvement here as we had only 11 of them in June.
• Level 1-3 (pkgs prompting during default desktop installs or important for desktop installs): 16 complete languages. We "lose" Belarusian, Gujarati, Brazilian Portuguese, Romanian.
• Level 1-4 (adding pkgs prompting during other tasks): 16 (the same ones)
• Level 1-5 (adding important stuff such as apt, dpkg, aptitude): 9 complete languages. Those languages reaching the Grand Slam are: German, French, Galician, Japanese, Portuguese, Russian, Slovak, Swedish, Vietnamese

Changes are still planned for level 1: D-I developers are really active these days, particularly with the great "come back" of J r my Bobbio and the constant QA work by Frans Pop. I also tried to merge in some work done in Ubuntu's Rosetta and then interest those people who translate there to collaborate to D-I "upstream". This lead me to merge updates for Icelandic, Kazakh, Afrikaans, Malay, Welsh and Serbian. Contacts were made with the relevant translators:

• For Icelandic, the translation updates in Rosetta come from a woman whose login is "eeinarsdottir" but I couldn't succeed in getting an e-mail address to get in touch with her. She apparently lives in Finland if I believe Google and is also using "zorglubb" as nickname. Any hint to get in touch with her would be appreciated.
• For Kazakh, I tried to get in touch with the person who translated in Rosetta but got no answer as of now. In the same time, I tried to re-wake up Talgat, who's registered as the D-I translator but wasn't very successful.
• For Afrikaans, Friedel Wolff, the main maintainer of Pootle, is very interested in working on the translation, through Pootle of course. He was however very reluctant wrt our current policy to activate languages only when people complete "sublevels" 1 and 2....which would require about 6000 words to be updated. Scary for him, as it seems. I tried to get in touch with the translator in Rosetta....but got no answer.
• For Malay, the current translator (NB Liang) was very happy to get more strings translated because of the merge with Rosetta translations. He proposed the Rosetta translator to collaborate: no answer.
• For Welsh, I got a positive contact with Jonathan Price who did some work in Rosetta, completing the old work by Daffyd Harries (Welsh used to be complete in D-I in the past). We'll see if that goes further than "I'll have a look at it".
• By far the most positive contact was for Serbian. In about one week, I managed to get in touch with Veselin Mijuskovic and Marko Uskokovic, who work for the cp6linux project, funded by the Ministry of Telecommunications and Information Society of the Republic of Serbia. This project is aimed at creating a fully localized Linux-based distribution for use in Serbia, with support for Serbian (both cyrillic and latin), as well as regional languages of Serbia. Their distribution is currently based on Ubuntu. They did a lot of l10n work which, unfortunately, did not end up upstream as of now. They gave me access to their Pootle server and I'll try to get some of their work back in Debian.

My conclusion about all this is mitigated: I'm somewhat sorry to see some work happening in Rosetta, still without any connection with "upstream" work, with people apparently working without even some internal coordination and quite anonymously. I wonder if these people know that their work has few chances to end up anywhere, except in Ubuntu (for D-I translation, I even doubt it ends up somewhere: this is just unused work....until I grab it for D-I "suptream").

Day one of FOSDEM 2008 has now ended, and almost everything seems to have gone fine from my end. Note, "fine" is not "perfect"; there were some issues.

• Unfortunately, Lars fell ill, and couldn't make it. Shame; I was actually looking forward to meeting him again. Fortunately, Frans Pop offered to hold a replacement talk, and that talk went well, given the low amount of time he had to prepare it.
• The Debian developer's room is now really too small. Last year, we were having issues with the room being too full to accomodate new attendees, but this was very much dependent on the actual talk going on; the room couldn't accomodate the audience for all the most popular talks, but in general there were no issues. In contrast, this year around I haven't yet seen the room not being too small.
• The security staff sucks. Again, they kicked us out of the DevRoom before the agreed-upon time of 19:00. I'll need to remember that for next year, and not try to assign talks until the very last moment; perhaps stop by 18:45 or so...
• The idea to let my hair grow to prove to Nattie that it's ugly that way seems to have failed to meet its purpose. Darn. This is the last time I'll come up with such a lousy excuse for allowing my hair to grow.
• I've been slacking with things, and not following up on stuff people sent me mails about. As a result, I needed to fix some things at the last minute while the event was already underway. Silly me. Most things worked out nicely, however; and the booth—I think I shouldn't bother to make up a schedule anymore next year.

Nothing spectacularly problematic; and as for the last item, that can be easily fixed by introducing fresh blood in organizing the Debian side of FOSDEM next year. Not that I want to stop being involved, but at least not being the only one responsible might be sensible. Other than that, no real issues, really. Well, except for one; I was so backlogged with everything that I had to postpone finishing my slides 'till the very last moment—half an hour ago. Ugh. But, well. Great FOSDEM!

Earlier today I watched the presentation Jonathan Oxer's gave during LCA about Package caching solutions. Although it was certainly an interesting presentation and although I very much agree that my current local mirror is wasting a lot of diskspace and bandwidth, I'm still not going to switch from debmirror to any of the available caching solutions, because (unless I'm really missing something) none of them scratches my itch. My local mirror currently consists of five architectures (i386, amd64, hppa, sparc and s390) and only has unstable and testing. I use it for:

1. (fast and convenient) updating of my systems
2. doing Debian Installer builds and installation tests
3. test builds of installation CDs (using debian-cd)

Now, the last one is somewhat hard (debian-cd uses hardlinks to packages on a local mirror instead of retrieving packages), so let's concentrate on the first two. Caching is great if you have a large number of machines – of the same architecture and that are all likely to need roughly the same packages – sitting behind the proxy: the first one triggers the download of the package and the rest gets it almost instantaneously. It is a lot less great if you have only one, maybe two systems per architecture: most of the time you'll still end up going down that (relatively) slow ADSL connection. An important reason why I have my mirror is so that when I do my daily updates for sid or run an installation test, the packages are already available locally. I really don't want to double or even treble the time needed for installation tests just because some required packages aren't yet available locally and need to be downloaded over that slow line. So, I have my partial mirror. Somewhat tuned (I exclude some ridiculously large debug packages for example, saving about 10GB), but still with a lot of junk^Wpackages on it I'll never ever use, especially for hppa, sparc and s390 as those systems only have fairly basic installations. Getting rid of that would significantly reduce my daily sync and allow me, for example, to also have a mirror of stable and oldstable, keep old versions of packages and probably still save a lot of diskspace. Wishlist What we should have is a hybrid solution: a program that will present itself as a proxy to clients, but is smart enough to pre-fetch new packages that are likely to be needed in a sync run, based on usage date from the the proxy and configuration settings. Some ideas for features/configuration options it could have:

• should support both source and binaries (debs and udebs)
• transparently retrieve packages that are requested but not available locally (just like a regular proxy)
• options to always sync (per architecture):
  • all required and standard packages
  • packages listed in a certain config file
  • packages in a certain section (e.g. udebs in the debian-installer section)
• for packages that have been used (requested by clients) within the last X days: pre-fetch any new version (per architecture)
• options to include security/volatile updates in that
• be smart about ABI changes: when a package name changes because the ABI version changes, also pre-fetch the new package; an alternative solution for that could be:
• for recently used packages: ensure that their dependencies are also pre-fetched; this would also provide support when packages are renamed (dependencies in the transition packages would ensure the new packages are pre-fetched)
• expire packages from the mirror that have not been used for X days
• allow faster expiration of certain types of packages (-dev or -dbg for example)
• options to keep X previous versions that are no longer referenced in the Packages files for Y days

Possibly such an implementation could even be used on some of the lower tier Debian mirrors. Unfortunately, unlike some of my esteemed colleagues, I'm not able to just whip up something like this, so I'm condemned to wait and see if there's someone else who'd like to pick up this idea. I am of course more than willing to help develop this idea further and to test it. Now, if I've totally failed in my research and something like this already exists, a pointer in the right direction would be much appreciated.

The first of my talks at LCA 2008 gave me a chance to talk about the current state of the Debian project, which got me my first LWN.net coverage with a photo, even (subscribers only for now, the article will become public on 7 February). Thank you, Jonathan Corbet, for a very good article which nailed all the main points! Slides are here. I agreed to this talk on short notice because I like to talk about Debian and was honoured by the chance to represent the project in this form. I would not have been able to do it without plenty of helpful input from colleagues in the last few days. Since I didn t get a chance to display the final slide with the acknowledgements during the talk, I would herewith like to thank specifically Andreas Tille, Michael Banck, Kevin Mark, Josip Rodin, MJ Ray, Cyril Brulebois, Stefano Zacchiroli, Frans Pop, Moritz M hlenhoff, Russ Allbery, Steve Langasek, Luk Class, Andreas Schuldei, and Christian Perrier. No guarantees for the completeness of the list. The talk ended in an open discussion on how Debian could improve. I took notes and shall forward them to the project mailing list, once I get a chance. Thanks to all the participants, as well. Update: during the talk, I mentioned that there was no security support around the time of the etch release. Thanks to Moritz M hlenhoff, who spotted my error: that should have been sarge . The problems with security support had long been resolved by the time etch was being prepared, and this was in (large?) part thanks to Moritz. Sorry for the screwup! I also called Linux to tend towards multimedia more than one might like. I should not have made this comment as a representative of the Debian project, and I probably did unjust to the Linux kernel in whole. This is entirely a personal issue, I have a number of problems with Linux memory management, scheduling, and some other points relevant to production use. I ve had some of these problems for years, but they seem never to get fixed, while development is fast-paced. Then I look at some of the work being done and I wonder what the priorities are. Regardless, I should not have made this comment and I apologise for it.

The traditional gathering of the Linux and FLOSS community in France will this year again feature a Debian booth. The event will be held in Paris-La D fense (CNIT), on Jan 29-31. As the Babelbox was born in that event three years ago, we will again have one, of course (people will get bored of it...). Frans Pop improved the thing so much that it took me less than 2 hours to set one up. We will also probably have a few other demo machines and the usual bunch of developers, contributors and friends popping up at the booth. If you're around, please come up and say "hi"....(don't forget fingerprints, IDs and some aspirin to cope with the verbiage of some of us who definitely talk too much).

Most audio players offer visualizations. Unfortunately most of them either are just plain boring or don't really visualize the music very well. KDE's amarok has one that is really excellent: jakdaw. Jakdaw does a good job of both following and representing the intensity of the music. And it generates an amazing display of colors. But even with a good visualization a lot of music is not all that interesting to watch. Over the last month or so I've occasionally been "looking" through my music collection. The visualizations are surprisingly varied for different artists. And though a lot of them are nice to watch, some artists consistently produce much more varied and artistic displays than others. To some degree it is predictable, but not always. Quite often the visualization is a lot less interesting than you'd expect and especially some slower or quieter songs produce much more interesting displays than you'd expect. A blanket of sound does not produce a very interesting display, but strong accents and mood changes do. As is often the case in art, the real challenge in composing music seems to be leaving things out and to have individual instruments play their own tune instead of having everything move together. The two artists that really stand out so far are Björk and Faithless. Both consistently produce visualizations that are at times stunningly beautiful and also show a lot more detail in the music than others. For Björk It's Oh So Quiet (from Post) and Violently Happy (from Debut) are very nice, but two songs that really stand out are Hunter (from Homogenic) and Hyper Balad (from Post). For Faithless songs like We Come 1 and Tarantula (from Outrospective), and Salva Mea and Insomnia (from Reverence) are truly worth watching.

Some more important things happened this week for Debian Installer i18n:

• First of all, Amharic was activated. The longstanding translation effort is reaching its end with Tegegne Tefera completing 87% of the core D-I translations and, more importantly, all strings for the most used packages. Amharic is the national language of Ethiopia and is indeed our second 'native' African language, after Wolof. This is indeed the first language we activate for lenny and that could be a sign of some revival in D-I i18n work.
• I also completed the tests phase of a new version of the 'synchronization script' that allows having all translatable strings for D-I package in a single (giant) PO file. Up to now, we were requiring translators to complete that file before we activate languages. However, many strings in the file are related to very rarely used features or high-end architectures. As the probably of someone installing Debian with LVM support on a s390 machine in something else than English is pretty low, we had to do something. So, very soon, the core D-I file should be splitted in five subfiles:
  • sublevel 1: default installs on common architectures
  • sublevel 2: general strings not used during default installs
  • sublevel 3: expert strings (some low prio, some for e.g. RAID)
  • sublevel 4: specific to less-popular arches (powerpc, mips, sparc) or used in experimental features
  • sublevel 5: same for high-end (hppa, ia64, s390) and hobby (m68k) arches and old stuff (partconf, partitioner, that are replaced by partman for a while)
  This will of course allow translators to better prioritize their work. We'll probably activate languages when translators complete the first two sublevels or so (that remains to be discussed). Thanks anyway to Frans Pop for the numerous good ideas he bringed when we discussed this.
• Armenian got its first commit in the D-I SVN. While the translated ratio is still very low, that's a positive sign
• Effort to translate D-I in Kashmiri should start soon as Rakesh Pandit seems very motivated to work on it
• Several languages from India should also soon raise their translation ratio: Kannada, Telugu, Marathi are expected...

All this work is meant to give some more push to D-I localization effort that paced for some time last months while I focused my attention on some other areas. It seems to show that things never work without someone to care about them, apparently..:-)...so, existing translators, watch out, I'm back on D-I i18n and will kick your asses if you don't keep your translations up to date..:-)

Sometimes it is extremely tempting to wave a huge, heavy, spiked cluebat around. Today I've decided to give in to this temptation. The case in point is the upload today by their maintainer of first cwidget and later aptitude. The fact that the maintainer blogged about both uploads probably means that he's pretty happy about it. Unfortunately I, and people in the Debian release team, were less than amused. Reason is that the uploads set back a complex transition of apt and related packages by at least a week. This is a transition we'd already been following and trying to get into testing for over a month and which was finally as good as ready to go. So what was so wrong about these uploads and what could (should?) the maintainer have done? First of all he should have realized that aptitude has become a rather central package in Debian with strong ties to apt and thus to a lot of other packages. Second, he should have checked whether his previous uploads had already migrated to testing and, if not, why not. The excellent testing migration page for aptitude (which is linked from its PTS page clearly shows that it is tied in a transition involving about a 100 packages in total. The right thing to do in such a case is to contact the release team (preferably at the debian-release mailing list, or at #debian-release). This would undoubtedly have resulted in a request to delay the uploads a few days until the transition had finished. Unfortunately that did not happen and cwidget was uploaded. Because of an ABI bump it ended up in NEW. Because of the transition I did a quick request to Joerg Jaspert to please delay accepting cwidget until the transition was over. But then a third mistake, and arguably the most serious one of the lot, was made. aptitude was uploaded for i386, built against the cwidget library which had not yet been accepted into unstable. Basically that means that an uninstallable package was uploaded. And of course it meant that at that point all efforts to finalize the transition for apt went down the drain. Some alternatives were discussed on how to deal with the new situation, including a sourcefull upload of the previous version of aptitude, but in the end it was decided to just accept the delay as one of the more annoying facts of life and instead ask Joerg to accept cwidget from NEW. In the end the damage may be a bit less than a week if the buildds cooperate (which they probably won't with cwidget still stuck at the wrong priority) and the RMs decide to force things. I sincerely hope that this story will make all Debian Developers and Debian Maintainers a bit more aware of the broader context and consequences of uploads. Oh, as I'm not an RM myself you may wonder what my interest is in this. We've got this great new feature in Debian Installer that adds support for multiple CDs during an installation (a feature that was lost with the integration of base-installer into D-I). However, we can only upload the relevant D-I component after apt 0.7.9 has reached testing...

Now available from alioth: debtree 0.7.2. The main change in this release is a much better display of virtual packages in dependency graphs.

• In regular depependency graphs debtree now shows which virtual packages are provided by the requested package, as can be seen in this example for debconf which provides debconf-2.0.
• If a virtual package is provided by multiple packages, these are now also displayed. To avoid clutter, by default the providing packages are only listed when there are three or less, but that number can be increased.

With this release I consider debtree "feature complete" when it comes to the information that is displayed in the graphs. A quick summary:

• can display both regular dependency graphs and build dependency graphs
• by default displays Pre-Depends, Depends, Recommends and unversioned Conflicts, and any Provides for the requested package
• can optionally display Suggests and versioned Conflicts
• clearly displays the packages from alternative dependencies
• can show what packages are already installed
• by default displays versions for versioned dependencies
• displays both Build-Depends and Build-Depends-Indep for build dependency graphs, and takes into account (or displays) architecture conditions in build dependencies
• has various options that can be used to limit the size/complexity of dependency graphs
• is lightning fast well, that is the next thing on the agenda; but it's not slow either!

Currently not supported are displaying Relaces, Obsoletes and Enhances relationships. If there's demand for it, adding them should be trivial. If you haven't yet, take a few minutes to look at the example graphs on the debtree website. What's next for debtree? You may remember that I filed an ITP when 0.7.1 was released but obviously its not in the archive yet. One reason is that debtree is completely redundant, at least if you consider the original reason I wrote it: to list how a package depends on another package. Just after the release of 0.7.1 I found out that aptitude why <package> <package> already provides that functionality!
I'm tempted to blame Enrico because I asked him if that was possible before starting on debtree, and Enrico really is supposed to know such things [1]! Luckily debtree now produces such nice dependency graphs to justify its existence :-) Anyway, I think that option should probably just be stripped out of debtree now. And if that is done, maybe it should be renamed to debgraph or apt-graph... I also discovered that beside apt-cache there was already another utility that produces dependency graphs: apt-rdepends. While, just like apt-cache, it lacks most of the features of debtree, it is quite fast and, because it is written in Perl, I could possibly port debtree to Perl myself using apt-rdepends as an example. Another reason is that a few people commented that maybe it should not be a separate package. I somewhat agree with that, but also would not like it to disappear in something non-descriptive like debian-goodies. I'd very much prefer it to eventually see it included in apt itself, or maybe in apt-utils. So basically I've been holding back a bit on uploading debtree to allow me to consider all this. The next task definitely is a rewrite in a better language and thereby give debtree a performance boost. [1] To his (and my) defence: that feature was only recently introduced in aptitude.

Frans Pop pointed me to etch arch qualify page where I saw m68k having just about 92% archive coverage.

After ftpmaster.d.o aka ries.d.o has been brought back again there was a problem for buildds without static IP address: the passwords for accessing incoming.d.o were apparently lost.

At least two weeks ago the right person to handle this issue has been informed, but as it seems that nothing happened yet. And it's difficult to keep the arch up to date when you can't access incoming and builds fail because of missing build-deps and are set to dep-wait.

Oh well... I wish that days would have 48 hours for some people who do seem to have too less time for all their work. sigh

Listmaster Thomas Viehmann wrote (IMHO) a very good summary for a policy on how to proceed with spam in the public archives of the Debian mailing lists. Some of them might need further discussions. Please help the listmasters and write your own ideas and opinions about his proposal. Also many thanks to Frans Pop, who first drafted some of them listmaster-internally quite a while ago. listmaster

Now available from alioth: debtree 0.7.1. The main change is the addition of a fairly comprehensive man page. Reviews of the man page would be most welcome. Having the man page also finally allowed me to file an ITP. Funny that this will be my first actual package in the archive. All my uploads so far have been team maintained D-I components and some NMUs.

I currently follow a few Debian mailing lists by scanning the list archives instead of being subscribed. I find that makes it a lot easier to not read everything and to resist the temptation to reply. I've also started following the linux-kernel mailing list, which has anywhere between 100 and 600 posts per day (and next to no spam). First through the archives at lkml.org; later I tried subscribing but that resulted in drowning in mail and some issues with the "ignore/watch threads" option in kmail made me unsubscribe again after a few days. I ended up subscribing to the linux.kernel news group instead, which works well as it's quite easy to tag threads 'ignore' and filter out ignored threads. In both cases the problem was that sometimes you do want to reply to a post, but how to do that without breaking the thread? My news reader is not smart enough that I can tell it to use the original mail headers, and for the list archives a solution is even less obvious. So I wrote a little script that allows me to just paste the subject and headers of a post directly from the Debian list archives. For the kernel list I configured my news reader to display some of the original mail headers, so I can also just paste those. The script will then parse the pasted info and generate correct Subject, To, CC, In-reply-To and References headers. With a few extra lines of code it even generates correct replies to bug reports. After that the script just calls 'mail' with the correct options which asks me to type/paste the body of the mail. Problem solved. So, just in case D-I colleagues were wondering if maybe I'd resubscribed to the d-boot list, the answer is "no".

Another nice new feature with debtree 0.7.0. The new version supports an option max-depth that can be used to limit the depth of a graph. I think debtree now supports all the ways to reduce the complexity of dependency graphs that can realistically be implemented in shell. A nice side-effect of this change is that it made it possible to also render other nodes in the graphs more consistently. Suggested packages now also have the diamond shape. And in sets of alternative dependencies "end" packages and unknown packages are now always marked as such. I also moved the previously hardcoded lists of "end" and "skip" packages to configuration files. These are managed using ucf which means that merging local changes with "upstream" updates in new releases will hopefully be relatively painless. If you have suggestions of packages to add to these lists, feel free to submit them. Please mail me both the command for the graph you'd like to reduce and the packages you're proposing to add to the lists. I have one issue left I'd like to implement: displaying alternative "Provides". And then I think its time to try to get debtree ported to C++.

---

P.S. You may encounter #443179 when using ucf. I've submitted a patch (several actually; the first two had a high "brown paper bag" ratio) that makes use of debconf's Choices-C feature, which should avoid this particular issue for future releases. Besides the mentioned advantage for substitution in templates of variables that need to be translated, Choices-C also allows developers to define a set of short aliases for choices that make the values used in a configuration script independent of the actual strings that are displayed to users. I doubt this feature is well known outside the D-I team. It was implemented in both debconf and cdebconf.

I've just "released" debtree 0.6.0. The number of options has almost doubled! It's now possible to suppress Conflicts and to generate full dependency graphs (including packages that are excluded by default). Unknown packages are now marked with a light reddish shading; this could possibly help finding obsolete Conflicts. I've also added verbosity options and fixed a few minor issues. But I'm most exited by two completely new features. Build dependency graphs Besides dependency graphs for binary packages, debtree now also generates build dependency graphs for source packages. It shows both Build-Depends and Build-Depends-Indep dependencies. It also takes into account architecture conditionals (such as [!s390]). It is possible to show such conditionals in the graph, but by default it will just omit any build dependencies not relevant for the selected architecture. Here's an example for dpkg. I expected this to be a lot harder to implement, but it proved relatively straightforward. I've been quite pleased with how extensible this script has proven. Show installed packages With this feature debtree gets back to its original purpose: providing information about what packages will get installed and why. When this option is activated, debtree will shade packages that are already installed light green. So if a graph is generated for a package that is not yet installed, it is easy to see what dependencies are already satisfied and what new packages will be installed. More importantly, you can also see which dependencies could be avoided because they are only recommended or which extra suggested goodies could be installed. Here's an example for clamav. This feature can of course also be used for build dependency graphs. Want to give it a try? The script or the Debian package can be downloaded from the debtree web page. That also has usage information and more examples. P.S. I've found yet another example of an undesired dependency on gconf2.

---

Update: fixed broken link

Martin Michlmayr reported Debian's 444444th bug yesterday, for those who like nice-looking numbers. This bug was reported against a Debian Installer package and closed a few hours later by an upload by Joey Hess. As one sees, even if the D-I team is still a little bit jerky after Frans Pop resignation as Debian developer and D-I release manager, the maintenance of the code is still happening. J r my Bobbio and Otavio Salvador, our new release managers, are still learning and building their knowledge to be able to release a beta version in the next months. New interesting mark in Debian's BTS is bug number 500000. It took 10 months (309 days) to go from 400000 to 444444. That means 695 days at the same rate to reach bug #500000 which means one can expect bug #500000 to be reached on Oct 18th 2008. But we all know that the bug report rate is not linear in Debian....:-) Update: thanks Frans for correcting my jerky English: "resignation" is better than "resignment".

Package dependency graphs on steroids

How an innocent and simple question can lead to strange development.

I was looking for a simple command that would tell me what the dependency path is from one package to some other package. That is, without having to go by trial-and-error using e.g. aptitude. Actually, I am getting quite annoyed by the fact that I regularly see e.g. gconf2 being pulled in when I install something on my (KDE-based) systems and I wanted to see how exactly they got pulled in. It should be possible to install e.g. xchat without being forced to install gconf2 too, right? For Sarge I had a similar issue with the gimp. Anyway, possibly there already is something to print dependency paths, but I did not find it. As I had some time free after dropping out of the Installer team, I decided to scratch my own itch. To get the paths I decided to recurse through dependencies using grep-available and friends, basically building a tree. An old wish was to play with dot, so I thought it would be nice to visualize the tree and so verify my code (conveniently forgetting about apt-cache dotty...). I soon had something basic working and after that it turned out to be irresistible (and surprisingly easy) to keep adding functionality. The result is that I can now produce graphs like: This is a fairly simple example. A lot of graphs are much more interesting. Oh, yes, it also answers my original question:

$ debtree xchat gconf2
xchat -> xchat-common (D) -> gconf2 (D)

The script is quite flexible and now looks solid enough for a first (Beta) release. After a few optimizations the shell script is even acceptably fast (or at least not slow) on my box. Euhh, what? Shell script? Yes. As I don't really know any of the popular languages used in Open Source, writing this in e.g. perl would just have taken too much time. OTOH, after some three years of working on D-I, I have become quite fluent in shell script. After all, about 80% of the installer (almost all functionality that does the actual installations — including the partitioner) is written in shell, so complex systems in shell are perfectly possible; thanks to Joey we even have a web server in shell! And it keeps surprising me how structured you can work in shell if you try a little. So there. Of course I'd like to see debtree re-implemented in another language, mainly to improve performance. Probably in C++ as that is what apt-cache is written in and its 'dotty' function could be a nice starting point. You'll understand from the above that I'm not going to do this myself, so if anybody is interested in working with me to do this, please contact me. debtree seems like it would be a nice addition to Debian, maybe even alongside apt-cache in apt... Enjoy!

debootstrap’s now team maintained under the debian-installer subversion repository; uploaders are Joey Hess, Frans Pop, Junichi Uekawa and myself. Rumours are Colin Watson might be joining in too. There’s a few changes committed, but an upload hasn’t been made yet – at least last I checked. Frans is applying pressure to bump the version to 1.0, as he seems to think it’s ready for production use. ifupdown’s had a maintainer upload, albeit to experimental – consider it a response to the competitive threat of madduck’s netconf. Changes are pretty minimal – it now uses iproute instead of ifconfig, there’s a “-o” option for ifup that lets you say things like “ifup -o wireless_essid=DebConf7 eth1” instead of having to edit /etc/network/interfaces. There’s a couple of backwards-incompatible changes unfortunately, so some other development’s needed before it will be suitable for unstable. In other red-letter news, the bzr archive for dak is up to date compared to what’s in use on ftp-master. Take advantage while you can! dak continues to stand for “debian-archive-kit”, not “debian-archive-kilt” however.